The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also correspond to embodiments of the claimed inventions.
Any programmer or software engineer can readily attest to the need to perform debugging and software quality testing and compliance operations on executable code. For example, the need to perform debugging operations may arise when new functionality is authored, when existing programs are modified to introduce new features or functionality, or when systems and datastores that are referenced by the executable code are modified in some way.
More specifically, syntax errors may be introduced when an executable program is authored, such as a missing semi-colon or a mistyped variable name or type, or logic errors can be similarly introduced, some of which may not be discoverable via automated compiler and syntax checking tools.
In a traditional implementation, executable code is authored by a programmer on behalf of a host organization and then executed within that host organization. In such an environment, the host organization may have a “live” or a “production” environment in which executable code is released and serves to fulfill the business objectives of the organization. In such a traditional implementation, the host organization may also utilize a “test” environment or a “sand-box” environment that closely replicates the production environment, but in which unreleased code can be tested for quality and compliance without negatively impacting actual customers of the host organization that are utilizing the production environment.
Generally, such a structure is a “single-tenant” environment in which a single host organization utilizes underlying hardware and software operating within the host organization to execute the executable code. Because the environment is a single-tenant environment, traditional debugging utilities are sufficient to debug code (e.g. by stepping through the code either line by line, or progressing up to a designated point, at which execution is stopped, allowing the programmer to analyze the detailed program flow, the status of variables, including their contents and input/output (TO) operations to datastores, databases, memory, or to files, and so forth).
Traditional debugging utilities however are insufficient for debugging executable code within a “multi-tenant” environment in which underlying software and hardware elements within a host organization are shared by multiple distinct and, usually, remotely located customer organizations.
For example, traditional debugging utilities require that execution of a tested codebase has to be halted, stopped, or paused at specified points as designated by the programmer for further analysis. Although stopping code execution within a single-tenant environment is acceptable as no other entity is impacted, stopping code execution in a multi-tenant environment is not acceptable as execution would be stopped for all entities on the shared hardware and software resource elements provided by the host organization.
A test-environment that does not allow for concurrent execution of multiple tenants' code bases who are sharing the underlying hardware and software resources could be utilized instead, however, such a test environment would not closely replicate the actual production or live execution environment of a multi-tenant execution environment, and thus, would not provide an adequate test, debug, and quality verification environment, due to the differences between the production execution environment and the modified testing environment.